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Abstract — Context'. Model-Driven Security (MDS) is as a spe¬ 
cialised Model-Driven Engineering research area for supporting 
the development of secure systems. Over a decade of research on 
MDS has resulted in a large number of publications. 

Objective: To provide a detailed analysis of the state of the art 
in MDS, a systematic literature review (SLR) is essential. 
Method: We conducted an extensive SLR on MDS. Derived 
from our research questions, we designed a rigorous, extensive 
search and selection process to identify a set of primary MDS 
studies that is as complete as possible. Our three-pronged 
search process consists of automatic searching, manual searching, 
and snowballing. After discovering and considering more than 
thousand relevant papers, we identified, strictly selected, and 
reviewed 108 MDS publications. 

Results: The results of our SLR show the overall status of 
the key artefacts of MDS, and the identified primary MDS 
studies. E.g. regarding security modelling artefact, we found that 
developing domain-specific languages plays a key role in many 
MDS approaches. The current limitations in each MDS artefact 
are pointed out and corresponding potential research directions 
are suggested. Moreover, we categorise the identified primary 
MDS studies into 5 principal MDS studies, and other emerging 
or less common MDS studies. Linally, some trend analyses of 
MDS research are given. 

Conclusion: Our results suggest the need for addressing multiple 
security concerns more systematically and simultaneously, for 
tool chains supporting the MDS development cycle, and for more 
empirical studies on the application of MDS methodologies. To 
the best of our knowledge, this SLR is the first in the held of 
Software Engineering that combines a snowballing strategy with 
database searching. This combination has delivered an extensive 
literature study on MDS. 

I. Introduction 

With more and more IT systems being developed and 
used, approaches for systematically engineering secure IT 
systems are becoming increasingly important. Model-Driven 
Security (MDS) emerged more than a decade ago as a special 
area of Model-Driven Engineering (MDE) for supporting the 
development of secure systems. MDE has been considered 
by some researchers as a solution to handle complex and 
evolving software systems [Bezivin2006] . It leverages models 
and transformations as main artefacts at every development 
stage. MDS specialises MDE by taking security requirements 
and functional requirements into account at every stage of the 
development process. By modelling and manipulating models, 


the level of abstraction is higher than code-level that brings 
several significant benefits, especially regarding security en¬ 
gineering. First, security concerns can be considered together 
with business logic and other quality requirements such as per¬ 
formance from the very beginning, and throughout the MDS 
development life cycle. Second, reasoning about systems at the 
model level, e.g. with model-based verification and validation 
methods, makes it possible to check security requirements and 
other requirements at early design stages. These methods can 
perform formal verification as well as security testing based 
on models. Moreover, models that abstract away from target 
platform details can increase cross-platform interoperability. 
Third, MDS can be more productive, and supposedly less 
error-prone than traditional development methods by leverag¬ 
ing automated model-to-model transformations (MMTs) and 
model-to-text transformations (MTTs, code generation). 

For more than a decade since MDS first appeared, a 
considerable number of MDS publications has shown a great 
attention of the research community to this area. The MDS 
approaches vary greatly in many artefacts such as the security 
concerns addressed, the modeling techniques used, the model 
transformations techniques used, the targeted application do¬ 
mains, or the evaluation methods used. To provide a detailed 
state of the art in MDS, a full systematic literature review 
(SLR) is needed. 

So far, a full SLR on MDS does not exist. Surveys on 
MDS approaches ([Kasal:2011:MDM:1955602.1956038, 
Basin:2011:DMS:1998441.1998443, AdvMDS, 

Uzunov:jucsl8'20:engineeringsecurityintodistributed]) 

could provide in-depth analyses of some well-known MDS 
approaches, but do not summarize the complete research 
area systematically. [Jensen:2011:SMD;2065363.2066253] 
could be closer to our work, but has several limitations 
in terms of scope and methodology. E.g., it missed many 
important primary MDS approaches such as UMLsec 
[Jurjens2002], and aspect-oriented approaches. In contrast, 
our SLR is performed in both width and depth of MDS 
research that reveals an extensive set of primary MDS studies. 
Furthermore, our review provides a detailed overview on key 
artefacts of every MDS approach such as used modeling 
techniques, considered security concerns, employment of 



model transformations, verification or validation methods, 
and targeted application domains. Finally, we present trend 
analyses for MDS publications, and for the addressed security 
concerns and other key artefacts. 

This paper is an extended and improved version of 
[Nguyen:APSEC2013]. In the previous version, we reported 
the results of a SLR based on 80 MDS papers found from 
an automatic search and a rigorous selection process. In this 
extended version, we improved our set of primary MDS papers 
by conducting two more search strategies; manual search and 
snowballing. On the resulting set of 108 finally selected MDS 
papers, we performed more detailed analyses for key artefacts, 
primary MDS studies, and trend analyses for a period of more 
than a decade. 

The main contributions of this paper are; 1) detailed and 
condensed results on key MDS artefacts of all identified 
primary MDS publications; 2) a diagnosis of limitations of 
current MDS approaches with suggestions for potential MDS 
research directions; 3) a classification of principal and emerg¬ 
ing/less common MDS approaches; and 4) trend analyses. 

The remainder of this paper is structured as follows. Section 
[n] provides some main background concepts and definitions 
that are used in this paper. The objective of this SLR, its 
research questions, search strategy, and selection process are 
described in Section III In Section IV we present our evalua¬ 
tion criteria and data extraction strategy. Section shows the 
main results of our review. Threats to validity are discussed in 
Section VI In Section |VII^ , we position this work regarding 
related work. Section |VIII| concludes the paper by summarising 
the results, highlighting open issues, and giving some thoughts 
on future work. 


II. Background Concepts and Definitions 
A. Systematic Literature Review and Snowballing 

SLR is a means for thoroughly answering a particular 
research question, or examining a particular research topic 
area, or phenomenon of interest, by systematically identi¬ 
fying, evaluating, and interpreting all available relevant re¬ 
search [Kitchenham'2007]. Well-known guidelines for con¬ 
ducting SLRs in software engineering were provided by 
Kitchenham'2007 and hiolchini2005systematic All individ¬ 
ual studies that are identified as relevant research contributing 
to a SLR are called primary studies [Kitchenham'2007]. 
In this paper, based on the numbers of publications and 
citations of primary MDS studies, we further classify them 
into principal MDS studies, and less common or emerging 
MDS studies. 

In a SLR, it is crucial to transparently and correctly identify 
as many relevant research papers in the focus of the review 
as possible. The search strategy is key to the identification of 
primary studies and ultimately to the actual outcome of the 
review [Wohlin2013]. The guidelines by Kitchenham'2007 
for SLRs in software engineering suggest to start with a 
database search that is based on a search string and also 
called automatic search in this paper. They also recommend 
complementary searches, e.g. a manual search on journals and 



conferences proceedings, references lists, and publications lists 
of researchers in the field. 

Both automatic search and manual search have limita¬ 
tions [Wohlin2013]; The former depends on the selection of 
databases, on database interfaces and their limitations, on the 
construction of search strings, and on the identification of 
synonyms. The latter depends on the selection of research 
outlets, e.g. journals or conferences, and cannot be exhaus¬ 
tive. Therefore Wohlin2013 proposed the snowballing search 
strategy as a first step to systematic literature studies. The key 
actions of the snowballing search strategy are; 1) identify a 
starting set of primary papers; 2) identify further primary pa¬ 
pers using the reference lists of each primary paper (backward 
snowballing); 3) identify further primary papers that cite the 
primary papers (forward snowballing); 4) repeat steps 2 and 3 
until no new primary papers are found. We are convinced, that 
the snowballing search strategy complements the automatic 
and manual search strategies of Kitchenham'2007 In our SLR 
we defined and performed a snowballing search strategy that 
builds on the set of primary papers found in automatic and 
manual searches. Details of our search strategy are presented 
in Section Uni 


B. A Definition of MDS 

Numerous security engineering techniques exist which sup¬ 
port the development of secure systems. There are also many 
MDE techniques for the development and maintenance of 
software systems in general. Our focus, however, is only on 
MDE approaches that are specifically customized for sup¬ 
porting the development of secure systems. As we already 
mentioned, MDS can be considered a subset of MDE. We will 
now clarify the relations between MDE, Model-Based Engi¬ 
neering (MBE), Model-Driven Development (MDD), security 
engineering, and MDS, which are important for our inclusion 
and exclusion criteria (Section III-C| l. Regarding MBE, MDE, 
and MDD, we agree with the point of view presented by 
BrambillaCabotWimmer201209 Specifically, MBE can be 
used for development processes in which models may not 
necessarily be the central artifacts for development. E.g., if 
models are only used for documentation purposes and not in 
automated transformations. MDE can be seen as a subset of 
MBE in which models have to be the key artifacts throughout 
the development, i.e. models “drive” the process in every 

















step: All development, evolution, and migration tasks have to 
be influenced by explicit models. MDD can be considered 
a subset of MDE that only denotes development activities 
with models as the primary artifact. Normally, model-to- 
model transformations (MMTs) or model-to-text transforma¬ 
tions (MTTs) are used in MDD to obtain other models or to 
generate code. Thus, MDS refers to all research approaches 
that focus on a MDD process for building secure systems. 
Figure depicts these subset relations. 



III. Our systematic review method 


Our SLR method is based on the guidelines of 
Kitchenham'2007 and the snowballing strategy of 
Wohlin2013 We presented the motivation for our review 
in Section and state our research questions in the next 
section. Based on these research questions, we developed a 
review protocol, which was evaluated before conducting the 
review. Figure shows an overview of our SLR process. We 
combined an automated database search (Section |III-B2| i, a 
manual search in relevant journals and conference proceedings 
(Section III-B3[ ), and a snowballing strategy (Section III-B4[ ) 
to identify as many primary MDS papers as possible. For our 
predefined protocol we clarify the selection criteria (Section 
III-C| l to reduce a possible bias in the selection process 
(Section III-Dl. The quality assessment, data extraction and 


synthesis of the primary MDS studies are based on a fixed 
set of evaluation criteria (Section GY). The results obtained 
from classifying, synthesising, analysing, and comparing the 
data extracted from the primary MDS studies are presented 
in Section FV] 


A. Research Questions 

This SLR aims to answer the following research questions: 
RQl: How do existing MDS approaches support the 
development of secure systems? 

This question is further divided into the following subques¬ 
tions: 

RQl.l: What kinds of security concerns are addressed and 
what security mechanisms are used by these MDS approaches? 
RQl.2 : How do the MDS approaches specify or model 
security requirements together with functional requirements? 
Is there any tool that supports the modelling process? 

RQl.3 : How are model-to-model transformations (MMTs) 
used and which MMT engines are used? Is there any tool 
support for the transformation process? 

RQl.4 : How are model-to-text transformations (MTTs) used 
to generate code, including security infrastructure and config¬ 
uration? Which tools are used for the generation process? 
RQl.5 : Which methods were used to evaluate the approaches? 
What results have been obtained? 

RQl.6 : Which application domains are addressed by the MDS 
approaches? 

RQ2 : What are current limitations of existing MDS 
research? 

RQ3 : What are open issues to be further investigated? 



Fig. 2: An overview of our SLR process. 


B. Search Strategy 


We developed a hybrid strategy to exhaustively search for 
MDS papers. The goal was not to miss any relevant MDS 
paper and therefore to find as many primary MDS papers as 
possible. Our hybrid strategy consists of three parts: automatic 
search (Section |III-B2| ), manual search (Section |III-B3| l, and 
snowballing (Section III-B4i. In each step, we applied inclu¬ 
sion and exclusion criteria (Section |III-C| l to select primary 
MDS studies. 

1) Identification of a Search String : Based on the research 
questions (Sect. III-A| l, we created search terms to form 
search strings, e.g. model-driven, model-based, security. We 
divided our search terms into three categories: MDE (model- 
driven, model-based, model*, MDA, UML), modeling (spec¬ 
ify*, design*), transformations (transform*, code generation) 
and security. 

To form the search string, we used a conjunction that 
combines disjunctions of the keywords of each term group. 
We had to refine our search string several times to make sure 
that as many potential relevant papers as possible are reached 
and had to adapt it according to the required format of the 
search engines. 

2) Step 1: Automatic Search in Databases for Scientific 
Literature: Using the search string described earlier, we 
performed automatic search within five electronic databases 
for publications between 2000 and 2014: IEEE Xplor^ ACM 
Digital LibrarjG] Web of Knowledge (isifl ScienceDirect 


4eeexplore.ieee.org dl.acm.org apps.webofknowledge.com 

































(Elsevier^ and SpringerLink (MetaPress^ 

3) Step 2: Manual Search in Conferences Proceedings 
and Journals: To ensure the correctness and completeness 
of our review, we also conducted two manual searches: a 
manual search in potentially relevant peer-reviewed journals, 
and another one in potentially related conference proceedings. 
We selected journals and conferences that are highly ranked 
either in the domain of software engineering (SE) or security 
and privacy (S&P). We manually searched for all published 
papers from 2001 to 2014 in 10 journals and 10 conference 
proceedings as shown in Table 0 and|g 

The 10 journals are chosen based on the relevance, the 
high impact index (Journal Citation Reports 2011), and the 
field ranking in the last 10 years according to the Microsoft 
Research website. 6 journals from SE and 4 journals from 
S&P were selected. We added the Empirical Software 
Engineering journal in order to find empirical validations of 
MDS approaches. The 10 conferences are also chosen on the 
relevance, and the conferences field ranking in the last 10 years 
according to the Microsoft Research website. 

4) Step 3: Snowballing for a complete set of primary MDS 
papers: The automatic search and manual search processes 
yielded a set 95 primary MDS papers. To make sure that 
our final set of MDS papers is complete we adopted the 
snowballing strategy presented by Wohlin2013 We use the big 
set of primary MDS papers provided by automatic and manual 
searches as input for our snowballing strategy as follows. 

Eigurej^shows how we formed the input set of MDS papers 
for snowballing. After conducting the automated search and 
applying the primary study selection procedures, we obtained a 
first set of 80 MDS papers (Step 1). Similarly, after conducting 
the manual search and applying the primary study selection 
procedures, we obtained a second set of 29 MDS papers 
(Step 2). We merged these two sets in order to form a set of 
selected MDS papers that was used for partially conducting 
our snowballing strategy. Jalali2012 provided a comparison 
between the SLR method and the snowballing method. They 
state that the snowballing method can be used to complement 
the automated search and manual search in terms of closing 
the final set of primary MDS papers. Because we already 
performed the automatic and manual searches for obtaining a 
set of 95 primary MDS papers, we only adopted the following 
3 out of 5 steps of the snowballing strategy: 

1) Backward snowballing: identify further potential pri¬ 
mary MDS papers in the reference lists of the current 
primary MDS papers. Initially this is the set of papers 
found by the automated search and manual search. 

2) Forward snowballing: identify further potential primary 
MDS papers by searching for papers that cite a cur¬ 
rent primary MDS papers. We used Google Scholaras 
recommended [Wohlin2013], because it captures more 
than individual databases. 

3) If no new papers are found by repeating steps 1 & 2, 
then identify further primary MDS papers by searching 

^ sciencedirect.com link.springer.com 



publications lists on personal homepages or author pages 
of database and institutions for the primary authors of 
the identified primary MDS approaches. This step was 
performed to ensure that the most recent publications 
on the same or similar topics are included. If additional 
papers are identified then go back to Step 1. 

Once no additional papers were found in step 3, we closed 
the cycle of identified primary MDS papers for data extraction, 
synthesis, and evaluation. 

C. Inclusion and Exclusion Criteria 

We already discuss our definition of MDS to give a better 
idea how we consider a paper as an MDS paper in Section 
Here, we show in detail the inclusion and exclusion criteria 
that have been used in our primary MDS studies selection 
process. 

MDS approaches for developing secure system vary a great 
deal as different security concerns can be addressed and 
different model-driven techniques can be used. Therefore, it 
was absolutely necessary to define thorough inclusion and 
exclusion criteria to select the primary studies for answering 
our research questions: 

7. Papers not written in English were excluded and already 
filtered out in our search process. 

2. Papers with less than 5 pages in IEEE double-column 
format or less than 7 pages in LNCS single-column format 
were excluded. 

3. Papers not concerned with MDE were excluded. For exam¬ 
ple, papers addressing security problems without using MDE 
techniques were excluded. 

4. Papers proposing model-driven approaches without a focus 
on security concerns were excluded. E.g., model-driven ap¬ 
proaches for performance analysis were excluded. 

5. When a single approach is presented in more than one 
paper describing different parts of the approach, we included 
all these papers, but still considerd them as a single approach. 

6. When more than one paper described the same or 










TABLE I: Journals used in our manual search. 


Acronym 

Full Name 

Field 

Rating 

TSE 

IEEE Transactions on Software Engineering 

SE 

56 

JSS 

Journal of Systems and Software 

SE 

34 

IEEE S&P 

IEEE Security & Privacy 

S&P 

31 

TISSEC 

ACM Transactions on Information and System Security 

S&P 

29 

TDSC 

IEEE Transactions on Dependable and Secure Computing 

S&P 

28 

COMPSEC 

Computers & Security 

S&P 

27 

INFSOE 

Information & Software Technology 

SE 

27 

SOSYM 

Software and System Modeling 

SE 

27 

TOSEM 

ACM Transactions on Software Engineering and Methodology 

SE 

25 

ESE 

Empirical Software Engineering 

SE 

20 


TABLE II: Conference proceedings used in our manual search. 


Acronym 

Full Name 

Field 

Rating 

ICSE 

International Conference on Software Engineering 

SE 

60 

CCS 

ACM Conference on Computer and Communications Security 

S&P 

54 

S&P 

IEEE Symposium on Security and Privacy 

S&P 

49 

USENIX 

USENIX Security Symposium 

S&P 

39 

AOSD 

Modularity/Aspect-Oriented Software Development 

SE 

37 

NDSS 

Network and Distributed System Security Symposium 

S&P 

35 

ACSAC 

Annual Computer Security Applications Conference 

S&P 

29 

SACMAT 

Symposium on Access Control Models and Technologies 

S&P 

28 

ESORICS 

European Symposium on Research in Computer Security 

S&P 

24 

MODELS 

Model Driven Engineering Languages and Systems 

SE 

21 


similar approaches, we only included the one with the 
most complete description of the approach. E.g., an 
extended paper /^Nguyen:2014:TAOSD7 published in a 
journal will be selected instead of its shorter version 

7Nguyen:2013:MAD:2451436.24514457 published in a con¬ 
ference proceeding. 

7. Papers with insufficient technical information regarding 
their approaches were excluded. E.g., papers that neither 
provide a detailed description of secure models, nor a precise 
security notion, nor transformation techniques, were consid¬ 
ered incomplete and were excluded. 

8. Only papers with a MDD perspectiove, i.e. MDE papers in 
which models are central artifacts throughout the development 
phase, were selected. Papers using model-based techniques 
only for verifying or analyzing security mechanisms without a 
link to the implementation code were excluded. 

9. Papers with less than 2 citations per year minus 2 as 
reported by Google Scholar were excluded. 

With these 9 clearly defined inclusion and exclusion criteria, 
we were able to perform the selection process in a more 
transparent and less biased way. 


D. Primary Studies Selection and Its Results 

Here we present the selection process conducted while per¬ 
forming each search step in the three-pronged search process 
and its results. Eigure shows details of our whole selection 
process with all the numbers of MDS papers selected in each 
step. 

1) Selection Process in the Automatic Search Step: Table 


III shows the results of our automatic search that is explained 


as follows. The papers found from the repositories described 



Eig. 4: The Selection Process with all the steps 


TABLE III: Summary of the selection process based on 
Automatic Search 


Source 

IEEE 

ACM 

ISI 

SD 

SL 

Total 

Search results 

2997 

1506 

3299 

828 

2003 

10633 

After reviewing titles/keywords 

109 

90 

91 

24 

81 

395 

After reading abstracts 

78 

44 

35 

19 

61 

237 

After skimming/scanning 

31 

21 

17 

15 

20 

104 

After final discussion 






93 

Finally selected 






80 
































































Fig. 5: Our selection process while snowballing 


in Section III-B2 were divided among reviewers. For each 
paper, we first read the paper’s title, keywords, and the venue 
where the paper was published to see whether it is relevant to 
our research topic. If the title and keywords of a paper were 
insufficient for deciding whether to include or exclude it, we 
further checked the paper’s abstract. If the abstract of the paper 
were insufficient for deciding whether to include or exclude it, 
we further skimmed (and scanned if necessary) the paper’s full 
text. Once each reviewer had done selecting candidate papers 
from his repositories, all the candidate papers from different 
repositories were merged to remove duplicates. We kept track 
of this merging process to see which duplicates were found. 
Duplicated papers were directly included in the final set of 
selected papers. All other candidate papers, were discussed by 
at least two reviewers. Some border-line papers were checked 
by all reviewers. We maintained a list of rejected candidate 
papers, with reasons for the rejection, after discussion among 
reviewers. In the end, 80 MDS papers were selected. 

2 ) Selection Process in the Manual Search Step: 29 candi¬ 
date MDS papers were found in the manual search step. By 
merging with the set of 80 papers above, we obtained in total 
95 MDS papers. 

3) Selection Process in the Snowballing Step: After the 
first two steps, we conducted the snowballing as described 
in Section III-B4 However, once obtaining all the numbers of 


citations of every paper in the set of 95 MDS papers above, we 
found out that some papers are much less cited than others, 
or even having no citation at all. We argue that the papers 
without a minimum number of citations after getting published 
for a specific period could be considered as not significant 
in terms of research impact and continuation. On the other 
hand, we also were not too strict on this aspect. Specifically, 
we decided that papers with the number of Google Scholar 
citation^ less than 2 citations per year minus 2 are excluded. 
Thus, the selection criterion 9 about number of Google Scholar 
citations was added. This means we leave out the papers that 
are not active, and do not have a minimum impact after being 
published for more than 2 years. Of course, this also means 
the recent MDS papers published in 2013 and 2014 are not 
excluded by this citation criterion. 

In 95 MDS papers, 31 papers were removed according 
to this citation criterion. Consequently, we used 64 primary 
MDS papers as the input for our snowballing process. In 
the snowballing step, we also apply the citation criteriorj^ 
together with other criteria to select primary MDS papers. 
Details of our selection process while snowballing are shown 
in [Figure 5 It is also important to note that every MDS 


candidate paper is cross-checked by three reviewers before 
any inclusion or exclusion decision. After all three steps, we 
have ended up with 93 primary MDS papers. However, we 
realised that some MDS papers, which were removed because 
of the citation criterion, should be put back in the final set as 
“sidekick” MDS papers. The main reason is that those MDS 
papers contain extra details of the approaches presented in 
the selected primary MDS papers. A “sidekick” MDS paper 
is a true MDS paper that was only excluded because of 
the citation criterion. Every “sidekick” MDS paper is part 
of a primary MDS approach. If they were removed, some 
important properties of the relevant primary MDS approaches 
could be missing in the data analysis. E.g., a paper presents 
an empirical study of a primary MDS approach. We would 
miss that empirical study of the primary MDS approach if the 
“sidekick” paper was removed because of the citation criterion. 
Thus, 15 “sidekick” MDS papers were put back in the final 
set. In the end, the final set of 108 MDS papers is used for 
data extraction and evaluation. 


IV. Evaluation criteria & Data extraction strategy 

Classifications and taxonomies are important in any 
research domain, e.g. [crnkovic2011classiflcation], 
[mens2006taxonomy] . In this section, we describe a 
set of key artefacts of MDS that forms a so-called evaluation 
taxonomy of MDS. We derived our evaluation taxonomy 
from our research questions. Moreover, our evaluation 
taxonomy are also based on the synthesis of evaluation 
criteria described in [doi:10.1142/S0218194002001062] and 
[Kasal:2011:MDM:1955602.1956038]. Having an evaluation 
taxonomy makes it more systematic to assess key artefacts 

^The citations of these 95 MDS papers were dated on May 19, 2014 

'^The citations of MDS papers found in snowballing were dated on-the-fly. 











































of MDS as well as classify and compare different MDS 
approaches. 

Our taxonomy of MDS classifies different dimensions that 
one has to take into account while leveraging MDE techniques 
for developing secure systems. The elements of our taxonomy 
are described as follows. For each element, the data extraction 
strategy is described to show how we extracted data from the 
primary studies to answer our research questions. 

Security concerns; In this dimension, we classify primary 
studies according to the security concerns/mechanisms that 
the MDS approaches are dealing with. The range of security 
concerns is broad, e.g. authorisation, authenticity, availability, 
confidentiality, integrity, etc. We will count the number of 
papers addressing each security concern. Thus, security topic 
areas that addressed by the MDS approaches are measured 
quantitatively. 

Modelling approaches: Security concerns can be modelled 
separately or not from the business logic, and by using dif¬ 
ferent modelling techniques/languages. Primary studies can be 
classified by the paradigms of modelling, i.e. Aspect-Oriented 
Modelling (AOM) or non-AOM. In AOM approaches, se¬ 
curity concerns are modelled in separate aspect models to 
be eventually woven (integrated) into the primary model(s). 
Using AOM, security concerns can be modelled separately, 
modularly in design units (aspects) [sunmonds2005aspect]. 
Vice versa, in non-AOM approaches, security concerns are not 
modelled as AOM aspects. That means security concerns can 
be modelled together with business logic in every place where 
they are needed. But, we also classify as non-AOM approaches 
where security concerns modelled separately {separation of 
concerns) from the business logic that can be integrated later 
into the system. E.g., a non-AOM approach could (separately) 
specify an access control policy using a Domain-Specific 
Language (DSL^^ and then transform and generate XACMlj^ 
standard file for enforcing the access control policy. In other 
words, we would like to know the percentage of non-AOM 
approaches compared to the percentage of “full” AOM/Aipecf- 
Oriented Software Development (AOSD) approaches. Sepa¬ 
ration of concerns can be considered as a key principle to 
cope with modern complex systems. Furthermore, approaches 
are also classified by the modelling languages, e.g. UML 
diagrams, UML profiles, or some kinds of DSLs, used to 
model security concerns and business logic. The outcome 
models are classified as of type standard or non-standard, 
and structural, behavioural, functional or other types. The 
granularity levels of outcome models are also reviewed. 

Model-to-model transformations (MMTs) & tools: 
MMTs can take part in the key steps of the development 
process, e.g. for composing security models into business 
models or transforming platform-independent models (PIMs) 
to platform-specific models (PSMs). We extract data related 
to MMTs for answering the following questions: How well- 
defined are the MMTs rules? How MMTs are implemented? 

^http://marti nfowler.com/books/dsl.html 

^extensible Access Control Markup Language, a XML-based declarative 
access control policy language 


Using which MMT engines (e.g. ATlj^ QVT0 KERMETtQ 
Graph-based MMTs, etc.)? Is there any tool support for 
the transformation process? What is the automation level 
of MMTs: automatic (if entire process of creating the tar¬ 
get model can be done automatically), semi-automatic, and 
manual. Some information about the classification of MMTs 
should also be extracted to see if it supports well for the 
security mechanisms? E.g., endogenous MMTs or exogenous 
MMTs used? 

Model-to-text transformations (MTTs, code and security 
infrastructure generation) & tools: MDE also supports the 
development of secure systems by automatically generating 
code, including (partial) complete, configured security infras¬ 
tructures. Data should be extracted to see the main purposes 
of using code generation techniques. Is the whole system 
including security infrastructure generated? Or just the security 
infrastructure (configuration) is generated? Can fully code 
and security infrastructure be generated? Or just the (code) 
skeleton of the system is generated? Which tools are used for 
the code generation process? 

Application domains: MDS approaches are also classified 
on the target application domains of the secure systems. Some 
MDS approaches might target only a specific application 
domain. Some might explicitly be applicable to different 
application domains in general. Others might implicitly be 
applicable to different application domains. Some examples 
of application domains are information systems, web ap¬ 
plications, databases, secure smart-card systems, embedded 
systems, distributed systems, etc. The application domains 
might be overlapping but could show relatively the intended 
application domain(s) of a specific MDS approach. 

Evaluation methods: To point out the limitations of each 
approach, we check again how the approach has been eval¬ 
uated. How many case studies have been performed? What 
results have been obtained? What other evaluation methods 
(other than case studies) have been applied to evaluate these 
approaches? This can be answered by extracting data from the 
validation section of each paper. 

To make the data extraction consistent among the reviewers, 
we all tried to extract the relevant data from a small set of 
prospective primary papers. We then discussed to ensure a 
common understanding of all the extracted data items and 
refined the data extraction procedure. Excel files were used 
for storing the extracted data while a tool called Mendelejj^ 
was used in reviewing and controlling the selected papers. 
The final set of primary studies (selected papers) was divided 
among reviewers. Each reviewer examined again the allocated 
papers and enriched the Excel files to ensure detailed data ac¬ 
cording to the taxonomy has been extracted from the selected 
papers. The data extraction forms of each reviewer were read 
and discussed by two other reviewers. All ambiguities were 
clarified by discussion among the reviewers. 

^http://www.eclipse.org/atl/ 

*http://projects.eclipse.org/projects/modeling.mmt 

® www.kermeta.org 
http://www.mendeley.com/ 


To answer the last two research questions, we reviewed the 
range of security topics, the scope of MDS research work and 
the quality of MDS research results to determine whether there 
are any observable limitations and open issues. 


V. Results 


First, in Section V-A we report on some statistic results 
according to the evaluation criteria. Then, the principal MDS 
approaches and other emerging/less common MDS approaches 
are revealed and described in Sections V-B V-C| respectively. 
Finally, Section |V-D| analyses the trends of some key factors 
in MDS. 


A. Results per Evaluation Criterion 

An overview of the results can be seen in Figures and 
Table Fig. shows the statistics about how each security 
concern has been addressed by the primary MDS approaches. 
Fig. 0 visualises other key results for a representative set of 
evaluation criteria. Table |lV] summarises all the values for all 
evaluation criteria. We present the results for each evaluation 
criterion as follows. 

Security concerns/mechanisms; Fig. shows the statistic 
of security concerns tackled by the reviewed MDS approaches. 
We can see that authorisation is addressed the most, by 75% 
of the examined MDS papers. Moreover, more than half of 
the MDS papers (53%) deal with authorisation only (Fig. 
|^,b). The second security concern in terms of receiving 
attention is confidentiality addressed by 42% of the exam¬ 
ined MDS papers. 11% of the examined MDS papers tackle 
confidentiality solely (Fig. |^,b). Other security concerns, like 
integrity, authentication, and availability are, however, less 
tackled with 27%, 24%, and 16% correspondingly. These 
results suggest that more MDS research work should focus 
on particular security concerns like integrity, availability, and 
authentication. 

We also would like to know how much multiple security 
concerns are tackled at the same time by the MDS approaches. 
Fig .|^ displays the statistic about how much three key security 
concerns (Authentication, Authorisation, and Confidentiality) 
are tackled solely and simultaneously. Only 13% of the 
examined MDS papers propose methodologies to tackle all 
three together. About 15% of the examined MDS papers 
deal with two concerns simultaneously: Authentication and 
Authorisation (3%), Authentication and Confidentiality (6%), 
Confidentiality and Authorisation (6%). Not only multiple 
security concerns are less tackled, but also rarely the inter¬ 
relations among multiple security concerns are formally taken 
into account in the reviewed MDS approaches. Future MDS 
approaches should address multiple security concerns simul¬ 
taneously, systematically by formally specifying inter-security 
concern relations. The inter-relation among security concerns 
have to be taken into account while developing DSLs for 
specifying security requirements. 

These first results are very interesting. Indeed, an open 
question is “why in MDS authorisation and confidentiality got 
more attention?”. A possible answer could be that MDS is a 


relatively young research area with more “model-driven” than 
“security”. MDS is the common name of the MDE approaches 
specifically focusing on secure systems development. Thus, 
among the authors of the published MDS papers, there are 
significantly more researchers with MDE background than se¬ 
curity engineering background. Researchers that mainly work 
with MDE techniques may first address authorisation (e.g. 
AC) because it is closer to application logic and functional re¬ 
quirements than other security concerns. This could be linked 
to the nature of security concerns. Some security concerns (e.g. 
authorisation) are closer to the application level than others. 
MDE researcher might not be familiar with security concerns 
to be addressed at the network layer. Given the background 
of the authors of the most renowned MDS approaches, it 
might be that we need more interest in MDE from the 
security engineering community to see more MDS approaches 
dealing with security concerns like integrity, availability, and 
authentication. Therefore, we suggest that more effort should 
be put into communicating MDE techniques as well as MDS 
approaches to the security engineering community. 

Modeling approaches: Eig. shows that 87% of the ex¬ 
amined papers used standard UML models and defined DSLs 
for security concerns using the profile and stereotype mecha¬ 
nisms of the UML. 13% used other DSLs (e.g. [Morin2010], 
[Menzel2009] , or [Mouelhi2008]). Thus, we understand that 
standardised, common UML models are broadly used by MDS 
approaches. On the other hand, defining DSLs (either UML 
profiles or other DSLs) is also very popular to leverage MDE 
techniques for secure systems development. UML profiles and 
other kinds of DSLs have been developed to better capture the 
specific semantics of security concerns. In other words, defin¬ 
ing DSLs plays a key role in MDS because that way allows 
expressing security concepts/elements more easily. However, 
using UML profiles is not the only way for developing DSLs in 
MDS approaches. DSLs which are not UML profiles are also 
recommended, especially DSLs that can deal with multiple 
security concerns in the same system. 

15% of the papers discuss approaches that are based on 
AOM (Eig. 1^) where security concerns are specified as as¬ 
pects and eventually woven into primary models. Even though 
the remaining 85% are not really aspect-oriented, most of them 
still follow the separation of concerns principle and really 
separate security concerns from the main business logic In 
most of the cases, security concerns were specified separately 
from the business logic in PIMs and transformed into PSMs 
that can be refined into security infrastructures (e.g. XACML) 
integrated with the systems. 

Security concerns are often modelled and analysed with a 
DSL that is concern-specific. But, few MDS papers have well- 
defined semantics for their languages so that these languages 
can be used for formal analysis. Only some papers related 
to the UMLsec, SecureUML approaches (see Section V-B i 
provide some formal basis for security analyses. This shows 


"Note that in this paper we only classified a modelling approach as AOM 
if a concern is modelled as an aspect model that can be woven into a primary 
model. We explained this point in Section [Tv] 
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Fig. 7: Statistics of some key MDS artefacts 













that further efforts are required to mature security-specific 
modelling languages to foster analyses. Most (89%) of the 
MDS papers use structural models. Behavioural models are 
used in 31% of the reviewed MDS papers. Other types of 
models like domain specific models accounted for 13%. Using 
solely one type of models could not be enough to be able to 
express multiple security concerns. Thus, very few modelling 
approaches propose to deal with multiple security concerns 
together like [Sanchez2010, Georg2009]. Most of them are 
specific to address only one security concern solely. 


Model-to-model transformations (MMTs) & tools; Table 


IV shows that 74% of the papers clearly mentioned MMTs 
while 26% did not use or mentioned transformations, e.g., 
because of a manual integration of security. More specifically, 
57% of the examined papers use exogenous transformations. 
Most of these were used to transform PIMs to PSMs (Fig.[^). 
Security concerns were modelled using DSLs for each concern 
to obtain PIMs that were transformed into PSMs, which can be 
refined into code. 19% define endogenous MMTs that are used 
to weave/compose security models into base models defined 
using the same DSLs. 


34% of the examined MDS papers implement automatic 
MMTs, 6% describe semi-automatic (interactive) MMTs, and 
only 4% are manual (Fig. [7^). But 56% do not specifically 
provide any implementation information about MMTs, e.g. 
some simply provide mapping rules for transforming models. 
Having automated MMTs is one of the key success factors 
of MDE [hutchison2011a] and MMTs play a crucial role in 
MDS as well. Especially some important semantics of security 
mechanisms might be embedded in the MMTs. Providing 
MMTs implementation details in MDS is important to evaluate 
the efficiency of each approach. It can be also helpful for other 
researchers to learn from previous experiences in choosing or 
developing a suitable transformation engine for their work. 
19% of the selected MDS papers describe their MMTs imple¬ 
mentation using standard transformation languages like ATL 
and QVT. 81% of the papers only describe the transformation 
rules without implementation details, or use other transforma¬ 
tion languages like graph-based transformations, or specific 
(Java-based) compilers/tools. 

Model-to-text transformations (MTTs) & tools: Table [Iv| 
shows that 64% of the papers describe MTTs or the generation 
of code or security infrastructures. 36% of the papers do not 
describe MTTs in details. Some mainly used models for veri¬ 
fying or analyzing implemented secure systems, e.g. UMLsec 
where code/security infrastructure generation is mainly men¬ 
tioned in future work. Comparing the purposes of MTTs, 
we can see in Pig. that there are nearly as many MDS 
papers (34%) that only generate security infrastructure, such 
as XACML or security aspects code, as the MDS papers that 
describe generation of both code and security infrastructure 
(29%). 


The tools used for code generation are not shown in Table 
[^because there are too many different tools. Besides Eclipse- 


TABLE IV; Results classified by the evaluation criteria 


Evaluation criteria 


# papers 

% 


Confidentiality 

45 

42 

Security concerns 
(overlapping) 

Integrity 

Availability 

Authenticity 

29 

17 

26 

27 

16 

24 


Authorisation 

81 

75 

Aspect-Oriented 

Yes 

16 

15 

Modeling/AOSD 

No 

92 

85 

Standard models 

Yes(UML/UML profiles) 

94 

87 

Other DSLs 

14 

13 

Type of models 


96 

89 


33 

31 

(overlapping) 

Others 

14 

13 

Transformations used 

Yes 

80 

74 

No/Unknown 

28 

26 


Endogenous 

20 

19 

Transformations level 

Exogenous 

62 

57 


Not Provided 

26 

24 


Automatic 

37 

34 

Transformations 

Semi-automatic 

6 

6 

automation 

Manual 

4 

4 


Not Provided 

61 

56 

Standard 

ATL/QVT 

20 

19 

Transformations 

Others/not mentioned 

88 

81 

Code generation 

Yes 

69 

64 

mentioned 

No 

39 

36 

Code + Security 
Infrastructures generated 

Yes 

Only Security Infrastructure 

Not Provided 

31 

37 

40 

29 

34 

37 


IS/e-commerce 

19 

18 

Application 

Data warehouses 

20 

19 

Domains 

Smart cards/ embedded systems 

7 

6 


Distributed Systems/SOA 

34 

31 


Others 

28 

26 

Type of validation 

Controlled experiment 

Industry case studies 

2 

5 

2 

5 


Academic case studies 

72 

67 


Example only 

23 

21 


Not Provided 

6 

5 


based MTT engines like XpANif*^ there are many cases where 
ad-hoc self-developed engines (e.g. Java-based tools, parsers, 
etc.) are used. A reason for that could be that many “ad- 
hoc” tools are preferred because of their specific support for 
a specific security domain. Ark [Wada2008|^ for example, 
transforms an input UML model designed with the proposed 
UML profile into a skeleton of application code (program code 
and deployment descriptor). More ad-hoc Java-based tools like 
the one in [Breu2007] generates code (XACML policy files) 
from the constraints specified in SECTET-PL The tool uses 
Antlr [parrl995antlr], a compiler program for the syntax 
analysis of the constraints. 

In general, MMTs and MTTs are widely used in MDS to 

*^https://www.eclipse.org/modeling/m2t/?project=xpand 
'^extends the code generation engine of the open Architecture Ware frame¬ 
work that was already migrated into Eclipse as Xpand 





















improve the productivity of the development process. Most of 
the primary MDS approaches do mention to leverage MMTs or 
MTTs by describing transformation rules/intentions. However, 
more than half of the primary MDS approaches did not provide 
implementation details of MMTs or MTTs. Not many primary 
MDS approaches use standard transformation languages/tools 
like ATL or QVT but rather ad-hoc tools like Java-based 
compiler/tools for engineering security into the system. With 
the progress in the maturity of standard MMT and MTT tools, 
they should be leveraged more in the future MDS approaches. 
Most of the MMTs in the selected studies are exogenous 
used for transforming PIMs to PSMs. The main reason is that 
there are many approaches (e.g. dealing with access control) 
generating only security infrastructure. Access control models 
(PIMs) often used to generate XACML configuration files 
(PSMs) for enforcing security policy. Another reason could be 
the lack of all-round approaches for the whole development 
cycle of secure systems which in the end lead to automatic 
generation of both code and security infrastructure. An all¬ 
round approach could follow AOM paradigm to fully leverage 
the automation of MMTs and MTTs for composing, trans¬ 
forming and generating both code and security infrastructure. 
Developing tool chains (based on MMTs and MTTs) to derive 
from models to implementation code is also an important piece 
of future work. Few complete tool chains to automate (most 
of) the MDS development process have emerged, but are still 
rare. 

Application domains: Fig. [7]F shows the main application 
domains that have been secured by MDS approaches. In gen¬ 
eral, these are distributed systems or SOA (31%), information 
systems or e-commerce (18%), data warehouses (19%), and 
smart cards/embedded systems (6%). The remaining MDS 
papers do not clearly state a domain, or could be genet¬ 
ically applicable for different application domains, such as 
[Sanchez2010, Kim2006, Mouheb2010, horcas2014aspect]. 

Evaluation methods: Most of the papers (67%) describe 
academic case studies used to evaluate their approaches. There 
are still quite many MDS papers (21%) which only provide 
“running examples” to illustrate their approaches. Few MDS 
papers show controlled experiments (2%) and industry case 
studies (5%) in the evaluation of their approaches. There 
are very few papers that provide an in-depth evaluation like 
[Clavel2008], [Soler2007b], and [Best2007]. Therefore, we 
suggest that more effort should be put in evaluating MDS 
approaches, e.g., with empirical studies or benchmarks. 

B. Principal MDS Approaches 

Altogether, the synthesised data show that there are cur¬ 
rently several MDS approaches that have been proposed, used, 
and discussed in multiple publications. We would like to 
identify the most influential MDS approaches in terms of 
numbers of publications and citations. In total, five primary 
MDS approaches, which are called principal MDS approaches, 
have been identified. They are summarised in Table [V] Each 
has at least 7 primary MDS papers in our final set. The details 
of each approach, except Secure data warehouses, can be 


found in [AdvMDS]. Here we briefly present each approach, 
and then compare some key points among them. 

SECTET firstly aimed at securing web services by lever¬ 
aging the Object Constraint Language (OCL) for specifying 
RBAC [Alam2004]. Based on that, a complete configured 
security infrastructure (XACML policy files) is generated. 
Later on, the authors proposed a specification language namely 
SECTET-PL (OCL-based) which is part of the SECTET 
framework for model-driven security for B2B workflows. In 
this framework. Constraint based RBAC (CRBAC) can be 
specified and then transformed into low-level web services 
standard artefacts [Alam2006b]. SECTET-PL is also used 
for modeling restricted (RBAC-based) delegation in Service 
Oriented Architecture [Alain2006a] . Their modeling approach 
is extended in [Architecture, PoUcies]. MMT and MTT 
are both carried out in a complete model-driven framework 
[Hafner2006, Breu2007, Breu2008]. SECTET mainly ad¬ 
dresses RBAC as its security concern and focuses on gen¬ 
erating security infrastructure (XACML), not all the source 
code. Recently, Memon2012 and also Katt2013 propose two 
pattern refinement approaches based on SECTET framework 
that allows flexible configurations of SOA security. 

Secure data warehouses (DWs) are the motivation 
for the work of developing MDS techniques for secure 
database development. This MDS approach is very spe¬ 
cific for developing secure DWs. Eernandez-medina2004, 
Eernandez-medina2004a extend OCL and UML for secure 
database development [Eernandez-Medina2005]. Their ap¬ 
proach also uses UML profiles for modelling security enriched 
PIMs as inputs for a model-driven framework to create secure 
DW solutions [Fernandez-Medina2007, Soler2009]. Secure 
PIMs can be transformed to secure PSMs by a set of formally 
deflned QVT rules [Soler2007a, Soler2007b, Soler2007]. 
These PSMs can then be used for generating code with security 
properties. A similar MDS approach for developing secure 
XML data warehouses is presented in [Vela2006, Carlos2010, 
Vela2012, Vela2013] More recently, the above mentioned 
techniques for secure DW development are also leveraged 
in a reverse engineering style to modernise legacy DWs 
[Blanco2014]. 

SecureMDD is proposed for facilitating the development 
of smart card applications based on UML models. In Se¬ 
cureMDD, UML class diagrams are used for modelling static 
aspects while UML sequence and activity diagrams are used 
for modelling dynamic aspects of a system [Moebius2009a]. 
Erom platform-independent UML models (PIMs) of a system, 
its formal abstract state machine (ASM) specification and Java 
Card code are generated. The generated abstract state machine 
specification is used for formally proving the correctness of 
the generated code regarding the security properties of the 
system. Thus, their MDS approach integrates MDE techniques 
with semi-formal and formal methods for verification as 
well as the implementation of security-critical applications 
[Moebius2009c, Moebius2009, Moebius2010]. The authors 
illustrated that SecureMDD is applicable for the development 
of large and complex secure Smart Card applications as well 





[Moebius2012]. The main limitations of SecureMDD are 
its specific application domain and the lack of analysis for 
consistency between the UML models and the ASM model. 

SecureUML is the approach which aims at bridging the 
gap between security modeling languages and design mod¬ 
eling languages. First, UML and UML profile are used 
for modeling application with role-based access control that 
can lead to generated complete access control infrastructures 
[Lodderstedt2002]. Then, Basin2006a propose a UML-based 
language (UML profiles) with different dialects, which forms 
modeling languages (such as SecureUML -h ComponentUML) 
for designing secure systems. Access control infrastructures 
for server-based applications can be generated automatically 
from models. Their work mainly focuses on access con¬ 
trol constraints based on RBAC in design models. Seman¬ 
tics of SecureUML (and ComponentUML) are provided by 
Brucker2006 and Basin2007, Basin2009 which enable formal 
analysis of security-design models. Based on this work, Clavel 
et al. show and discuss their practical experience of applying 
SecureUML in industrial settings [Clavel2008]. Recently, 
the work on SecureUML has been continued by combining 
SecureUML + ComponentUML with a language for graphical 
user interfaces (GUI), namely ActionGUI [basin2014model, 
Basin2011]. These modeling languages with MMT enable 
the full generation of security-aware GUIs from models for 
data-centric applications with access control policies. Another 
recent work by Dios2014 makes use of ActionGUI for model 
driven development of a secure eHealth application. The main 
limitation of SecureUML is its sole focus on access control. 

UMLsec is one of the most well-known UML-based 
approaches in MDS proposed early by Jurjens2002, 
Jorjens2002 Security requirements, threat scenarios, security 
concepts, security mechanisms, security primitives can be 
modeled by using security-related stereotypes (UML pro¬ 
files), tags, goal trees, and security constraints. Thus, it is 
possible to formally analyze UMLsec diagrams against se¬ 
curity requirements regarding their dynamic behaviors. Not 
like SecureUML only focusing on authorisation (e.g. access 
control), UMLsec addresses multiple security concerns such 
as confidentiality, integrity [Jan2005]. Not to a great extent 
but AOM is also used in the UMLsec approach [Jan2005a]. 
Later on, UMLsec is deployed by Best2007 in an industrial 
context for designing and analyzing designs of distributed 
information systems. On the other hand, relevant tools support 
for UMLsec are presented in [Jurjens2007]. To tackle also 
social challenges in security, UMLsec was combined with 
Secure Tropos [mouratidis2007secure] to take on security 
from requirement engineering phase [Mouratidis2006] . This 
work is then extended and applied to two different industrial 
case studies [Mouratidis2009] . A more recent work related to 
UMLsec is by Jan2011 for incremental security verihcation 
for evolving UMLsec models. However, UMLsec lacks support 
for improving productivity of the development process in 
terms of automated model transformations. Even having a 
view from models to code but the lack of automated trans- 
formation(s) from models to implementation code is a miss 


in UMLsec. Other than that, UMLsec could be considered as 
the most complete and mature MDS approach that deals with 
multiple security concerns, from very early at the requirement 
engineering level, with transformations, formal analysis pos¬ 
sibility, tools support, industrial case studies. 

In general, the most common point among the principal 
MDS approaches is that they all propose to use UML profiles 
in their modeling phase. Even though not following truly 
AOM, defining UML profiles as DSLs for modeling secu¬ 
rity concerns still allows these principal MDS approaches to 
have separation of concerns. Except SecureUML which only 
addresses access control, other approaches are able to touch 
multiple security concerns. Structural models are mainly used 
in all hve approaches. SecureMDD and UMLsec have also 
used behavioral models. Exogenous MMTs are defined in 
SECTET and SecureDWs to transform PIMs (UML models) 
to PSMs. SecureUML and UMLsec integrate security into 
systems specified in UML using endogenous MMTs. Se¬ 
cureMDD combine both kinds of MMTs in their development 
process. Some standard transformation tools are used (e.g. 
QVT and XPAND) among other self-developed tools (java- 
based compilers). With their formal background, SecureMDD, 
SecureUML and UMLsec provide some tools for formal 
verification of security properties. These three also have in¬ 
dustrial case studies while SECTET and SecureDWs have 
not. Generally, each approach is quite specific to a application 
domain, e.g. SecureDWs for secure database development, or 
SecureMDD for secure smart card development. 


C. Less common/emerging MDS Approaches 

It would not be fair to only discuss about the above- 
mentioned principal MDS approaches. There are other less 
common or emerging MDS approaches that are also worth to 
get noticed and analysed. We discuss some representative ones 
here. Eor the full list, readers are referred to Tables and 


VII The less common or emerging MDS approaches here are 


simply classified into several groups as follows. 

Pattern-based MDS; Based on domain-independent, time- 
proven security knowledge and expertise, security patterns 
can guide security at each stage of the development process. 
Some MDS approaches that leverage security patterns are 
remarkable. Abramov2012, Abramov2012a, Abramov2012b 
propose an MDS framework for integrating access control 
policies into database development. At the pre-development 
stage, organisational policies are specified as security patterns. 
Then, the specihed security patterns guide the definition 
and implementation of the security requirements which are 
defined as part of the data model. The database code can 
be generated automatically after the correct implementation 
of the security patterns has been verihed at the design stage. 
Their approach has been evaluated in a controlled experiment 
[Abramov2012b]. Also using security patterns but at a differ¬ 
ent level of abstraction, Kim2006, Kim2004 develop a pattern- 
based technique for systematic, model-driven development 
of secure systems focusing on access control. Because this 
work mainly focuses on the design stage, access control is 



specified as design pattern. Bouaziz2013 introduce a security 
pattern integration process for component-based models. With 
this process, security patterns can be integrated in the whole 
development process, from UML component modelling until 
aspect code generation. Another pattern-driven approach is 
proposed by Schnjakin2009 for facilitating the configuration 
of security modules for service-based systems. The proposed 
security advisor enables the transformation from the general 
security goals, via security patterns at different abstraction 
level, to concrete security configurations. Menzel2010a uses 
the security configuration patterns to operate the transfor¬ 
mation of architecture models annotated with security inten¬ 
tions to security policies. The patterns that provide expert 
knowledge on Web Service security can be specified using a 
DSL. As using cloud services provided by cloud providers is 
getting more popular, moral2014enterprise recently propose 
an enterprise security pattern for securing Software as a 
Service. The security solution provided by the pattern can 
be driven by making design decisions whilst performing the 
transformation between the solution models. Specifically, from 
a Computation Independent Model (cim), different PIMs can 
be derived based on different design decisions with security 
patterns. Those PIMs are transformed into PSMs which are 
then transformed into Product Dependent Models (pdms). 

MDS for Security® Runtime: Many modern applications 
such as cloud-based software-as-a-service (SaaS) applications 
require the dynamic adaptation or even evolution of both secu¬ 
rity and service at runtime. More and more (MDS) approaches 
have been being proposed in this area. almorsy2012mdse 
introduce an approach called Model Driven Security Engi¬ 
neering at Runtime (MDSE@R). MDSE@R is based on a 
UML profile with tool supports for separately specifying base 
system and security, and then merging those models into a joint 
system-security model. Because security and system models 
are separated and loosely coupled, they can evolve more easily. 
Security controls are enforced dynamically into the target sys¬ 
tem at the code level. After that, in [Alniorsy2013] the same 
authors leverage the MDSE@R approach for multi-tenant, 
cloud-hosted SaaS applications. This allows dynamically engi¬ 
neering security for multi-tenant SaaS applications at runtime. 
Recently, almorsy2014secdsvl develop a new DSL called 
SecDVSL for specifying visually a variety of security concepts 
like objectives, threats, requirement, architecture, and enforce¬ 
ment controls. SecDVSL also allows maintaining traceability 
among these security concepts. Not specifically for SaaS 
applications but component-based architecture, Morm2010 
leverage the notion of model@run.time to enable dynamically 
enforcing role-based access control policies into component- 
based systems. In the follow-up work, Nguyen:2014:TAOSD 
deal with not only access control policies but also the more 
complex, but essential, delegation of rights mechanism. The 
propose MDS framework allows dynamically enforcing/weav¬ 
ing access control policies with various delegation features into 
security-critical systems. This is done with a flexibly dynamic 
adaptation strategy. Another runtime-update of security policy- 
based approach is presented by Elrakaiby2014 The introduced 


DSL called Security®Runtime covers many of the security 
requirements of modern applications such as authorisation, 
obligation, and reaction policies. Xiao2009’s work is on adap¬ 
tive and secure multi-agent systems. The authors adopting the 
adaptive agent model to put forward a security-aware model- 
driven mechanism by using an extension of RBAC model. 

MDS for Secure SOA: Many MDS approaches focus on 
securing service-oriented systems (SOSs). Gilmore2010 show 
how services, service compositions, and non-functional prop¬ 
erties can be modeled using their self-developed UML profile 
and its extension. They address non-functional properties in 
general where security is considered with performance and re¬ 
liable messaging. The models are the input for the framework 
VIATRAp]to derive deployment mechanisms using MMT and 
MTT. Wada2008 also address non-functional aspects in SOA 
with a MDD framework and tool support. Their work is empir¬ 
ically evaluated to show the improvement in the reusability and 
maintainability of service-oriented applications. More specif¬ 
ically to integrate security-related non-functional aspects in 
the development of services, Gallino2012 present their MDS 
solution using multiple domain-specific models independently 
addressing security aspects. Hoisl2011, Hoisl2012 propose an 
MDS approach based on SoaML for specification and the 
enforcement of secure object flows in process-driven SOA. 
[Menzel2010, Menzel2009] introduce a security metamodel 
for SOA. This metamodel is the base for their MDS framework 
that allows modelling of security requirements in system 
design models. Going further than modelling, Nakamura2005 
propose an MDS tooling framework to generate Web services 
security configurations. In the same line, intermediate model 
structure is introduced by Satoh2006, Satoh2007 to simplify 
the transformation rules for transforming a security policy 
written in WebService-SecurityPolicy into platform-specific 
configuration files. 

Aspect-Oriented Modelling in MDS: AOM techniques 
would be ideal for MDS with fully separation of concerns 
support. With AOM, security concerns can be modelled sepa¬ 
rately, and then automatically composed into primary mod¬ 
els. All of the reviewed MDS approaches in this category 
except [Ray2004575, Zhu2009] tackle multiple security con¬ 
cerns. These approaches aim at dealing with multiple security 
concerns as one would expect from any AOM approach. 
Georg2009 propose a methodology that allows not only se¬ 
curity mechanisms but also attacks to be modelled as aspect 
models. The attacks models can be composed with the primary 
model of the application to obtain the misuse model. The au¬ 
thors then use the Alloy Analyser[^to reason about the misuse 
model. If the misuse model shows that the application is com¬ 
promised, some security mechanism must be incorporated into 
the application. The Alloy Analyser is used again to verify that 
the secured application model is now resilient to the attack. 
Mouheb2010, Moubeb2009a develop a UML profile that 
allows specifying security mechanisms as aspect models. The 

http://www.eclipse.org/viatra/ 

http://alloy.mit.edu 
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aspect models often go together with their integration speci¬ 
fication. Their approach allows security aspects to be woven 
automatically into UML design models (class diagrams, state 
machine diagrams, sequence diagrams, and activity diagrams) 
[Mouheb2010]. In [Mouheb2009a], the authors present a full 
security hardening approach, from design to implementation. 
Not only restricted to security aspects, Sanchez2010 propose 
a MDD approach for all early aspects, including security. The 
difference with other approaches is that they focus on aspect- 
oriented requirements specifications (models). These aspect- 
oriented requirements models are then automatically trans¬ 
formed into aspect-oriented architecture models. Not dealing 
with multiple security concerns, Ray2004575 introduce an 
AOM approach for addressing access control. Specifically, 
RBAC aspects can be modeled using parameterised UML 
models as patterns. This allows uniformly incorporate per¬ 
vasive access control functionality into a design. The woven 
model can be analysed to check the correctness of incor¬ 
poration. Zhu2009 propose a model-based aspect-oriented 
framework for building intrusion-aware software systems. 
There, attack scenarios and intrusion detection aspects are 
modelled using an aspect-oriented UML profile. The intrusion 
detection aspect models are used to automatically generate 
aspect-oriented codes. The aspect-oriented codes are woven 
into the target systems using an aspect weaver to obtain the 
intrusion-aware software system. Recently, horcas2014aspect 
propose a hybrid AOSD and MDE approach for automatically 
weaving a customised security model into the base application 
model. By using the Common Variability Language (CVL) and 
ATL, different security concerns can be woven into the base 
application in an aspect-oriented way, according to weaving 
patterns. However, inter-security concern relations have not 
been taken into account. 

MDS for Access Control: Section IV-AI shows that access 
control problem got the most attention from the MDS com¬ 
munity. We discuss here some representative MDS approaches 
that specifically address access control. Ahn2007 propose a 
framework for representing security model, specifying and val¬ 
idating security policy, and automatically generating security 
enforcement codes. This framework leverages the MDD ap¬ 
proach together with a systematic tool to build secure systems. 
Also presenting a MDD approach for access control, Fink2006 
aim at developing access control policies for distributed sys¬ 
tems using MOF and UML profiles. However, this approach 
does not work well with module-based system like systems 
based on SOAP[3 Kim2011 present a feature-based approach 
that enables systematic configuration of RBAC features for 
developing customisable access control-based enterprise sys¬ 
tems. Feature modelling is used for effectively capturing the 
variabilities of the RBAC. UML models are used for speci¬ 
fying the static and behavioural properties of RBAC features. 
The composition method in their approach is used for building 
RBAC configuration, which also serves as a verification point 
for correctness of composition. Aiming at a full design-to- 

http://www.w3.org/TR/soap/ 


testing MDD process, Mouelhi2008 introduce a generic access 
control metamodel. The generic access control policy model 
specified by the metamodel is automatically transformed into 
security policy for the XACML platform, and integrated in the 
target application using aspect-oriented programming. Model- 
based mutation testing makes the access control enforcement 
quantitatively testable. Pavlich-Mariscal2010 propose a MD 
framework with a set of composable access control features 
that can be tightly integrated into the UML. At the code 
level, access control is map to the policy code which realises 
access control diagrams and features, and the enforcement 
code, to restrict access to methods based on information of 
the policy code. The degree of traceability of mappings is 
assessed. Recently, schefer2014model propose a full MDD 
approach for specifying and enforcing break-glass policies 
in process-aware information systems. By tackling a com¬ 
plex security exception handling mechanism like break-glass 
policies with MDS, this work shows developing DSLs for 
specific security concerns are a good way to capture well the 
semantics of these concerns. Based on that, a typical MDD 
process can be developed for derive security from specification 
to enforcement with tools support. bertolino2014toolchain 
even go further in terms of tools support by providing a 
toolchain for designing, generating, and testing access control 
policies. This toolchain is the result of integrating specific tools 
for specific stages of the development cycle that have been 
developed in a collaborative research network. The research 
around UMLsec has also resulted in various tools support but 
not yet systematically formed a tool chain. 

Miscellaneous: Neisse2013 present one of few MDS ap¬ 
proaches about usage control, the next generation of access 
control. Consisting of authorisations and obligations, high- 
level usage control policies are specified considering an ab¬ 
stract system model and automatically refined with the help 
of policy refinement rules to implementation-level policies. 
The work by Elrakaiby2014 mentioned above can also be 
categorised as usage control. In the domain of securing em¬ 
bedded systems, the approach we reviewed is by Eby2007 The 
authors propose a framework to incorporate security modelling 
into embedded system design. Their security analysis tool 
is capable of analysing the flow of data objects through a 
system and identifying points that are vulnerable to attack. 
Not restricted to a particular application domain, ModelSec 
by Sanchez2009 can deal with multiple security concerns 
in an integrated fashion, including privacy, integrity, access 
control, authentication, availability, non-repudiation, and au¬ 
diting. ModelSec supports defining and managing security 
requirements by building security requirements models for 
an application from which operational security models can 
then be generated. Recently, busch2014modeling present an 
MDS approach specific for securing web applications, tack¬ 
ling multiple security concerns. The graphical, UML-based 
Web Engineering (UWE) language is extended for specifying 
security concerns in web applications. Moreover, the approach 
is mapped to an iterative development cycle from requirement 
specification to testing and deployment with tools support. 
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D. Trend analysis of MDS approaches 

In terms of publication, we can see in Fig.[^there was a peak 
time for primary MDS publications in 2009. As we mentioned, 
the primary MDS approaches were hrst introduced from 2002. 
From 2002-2008, more primary MDS papers were published at 
conferences than journals. The number of primary MDS papers 
published at conferences were going up until 2007. In 2008, 
the number of primary MDS papers published at conferences 
decreased. One of the reasons could be primary MDS papers 
were under submission to journals. In 2009, there was a peak 
number of primary MDS papers published in journals. After 
the peak in 2009, the trend of primary MDS publications looks 
more stable for the period 2010-2014. From 2010 to 2014, less 
primary MDS papers were published than the previous 5-year 
period (2005-2009). However, the trend of publishing primary 
MDS papers in the period 2010-2014 seems more stable. 

Similarly to the trend of publications, the trend of how 
security concerns have been addressed also has a peak time 
in 2009. Fig. shows that, nearly all the time reviewed, 
authorisation is the concern that has been addressed the most. 
Only in 2009, conhdentiality was tackled by more primary 
MDS papers than authorisation. The other concerns were 
always less focused than authorisation and confidentiality all 
the time reviewed. Until 2014, authorisation looks like still 
being addressed the most by the MDS research community. 
MDS researchers should pay more attention to the less tackled 
security concerns, and should aim at a solution addressing 
multiple security concerns simultaneously. 

The trends of how MDE artefacts leveraged in the primary 
MDS approaches look well coupled with the number of 
primary MDS publications. The line of each artefact is very 
close to the others (see Fig.[T0|i. This means that most primary 
MDS approaches did leverage the key artefacts of MDE in 
secure systems development. It is easily understandable that as 
long as we clearly dehne how an approach can be considered 
an MDS approach, most of the key MDE artefacts have to be 
leveraged in an MDS approach. This trend should hold in the 
future as well. 

In terms of publication venues. Information and Software 
Technology (1ST) journal and ACM/IEEE International Con¬ 
ference on Model Driven Engineering Languages and Systems 
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Eig. 9: Trend of security concerns addressed by MDS studies 
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(MODELS) are so far the most popular venues for publi¬ 
cation of primary MDS papers. Eig. 11 shows that at least 
10 primary MDS publications have been found in each of 
these two venues. The next two attractive venues for primary 
MDS papers are ARES (security conference), and SoSym 
(MDE journal). Primary MDS papers were also published at 
some other general journals (Journal of Universal Computer 
Science) or domain specihc conferences (IEEE International 
Conference on Web Services). The proceedings of Tutorial 
Lectures on Eoundations of Security Analysis and Design 
(EOSAD) contains some signihcant primary MDS approaches 
as well. In general, except ARES and CSJ, conferences and 
journals specihc for security do not seem to be the common 
venues for MDS publications yet. 


VI. Threats to validity 

We discuss the threats to validity of this SLR according to 
the lessons learned on validity in SLRs [Kitchenham'2007] 
and our own experience. 


A. The search process 

To maximise the relevant articles returned by the search 
engines, we kept the search string not too specihc but still 
rehecting what we wanted to search for. Moreover, the search 
string was used for searching not only in the titles, abstracts 
but also in the full text of an article. Only the search engine 
of Web of Knowledge (ISI) does not provide the option for 
searching in full text. This limitation could affect the search 
results returned by ISI. To minimise the possibility of missing 
relevant papers, we kept our search string generic so that 
we cover as many relevant papers as possible (more than 
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10 thousands relevant papers found). To complement for the 
automatic search, we have also conducted the manual search 
on relevant journals and proceedings of relevant conferences. 
Then, to mitigate the limitations of automatic and manual 
searches, we have adopted the snowballing strategy. Even 
though only three out of five steps of the snowballing strategy 
were adopted, those are the key steps. Moreover, we already 
conducted the extensive automatic and manual searches which 
covered thousands of relevant publications, and resulted in a 
large set of primary MDS papers. That is why conducting 
only three key steps of snowballing strategy would be fair 
enough. Another possible threat is that we did not extensively 
search for books related to MDS. However, we did include 
the option to also search for book chapters while performing 
automatic search. In fact, we found out some book chapters 
that got into our final selected papers for data extraction, e.g. 
[Architecture], [Jan2005]. 

B. Selection of primary studies 

A large part of the search and selection process was con¬ 
ducted by the first author. Some publications might have been 
missed. To mitigate this risk, every doubtful or ’’borderline” 
publication was not dismissed in the first place but rather being 
cross-checked and discussed by all the reviewers. Additionally, 
our clearly predefined review protocol with inclusion and 
exclusion criteria helped to reduce the reviewers’ bias in the 
selection of primary studies. 

The results of this SLR papers are based on the data 
extracted and synthesised from the selected MDS studies. 
Note that we have applied the citation criterion to estimate 
the quality and impact factors of the selected primary MDS 
studies. Even though this criterion is not too strict, applying 
it caused a number of MDS papers not to be included. We 
realized that some of the excluded MDS papers are related 
to the included primary MDS studies. To mitigate the risk 
of missing some important data of the primary MDS studies, 
we put back the excluded MDS papers that are related to the 
primary MDS studies. In total, we re-selected 15 MDS papers 
as the ’’sidekick” papers to be included in the final set for data 
extraction. 


Some key selection criteria in this SLR are time-bound. The 
citation criterion for selecting primary MDS papers is based on 
the numbers of citations provided by Google Scholar engine. 
The selection of venues for conducting manual search is based 
on Microsoft Research ranking website. Google citations will 
change from time to time. Similarly, rankings of conferences 
and journals will change. Those time-bound metrics influence 
the reproduction of this SLR. So, some papers which were 
not selected as primary MDS papers because of the citation 
criterion would satisfy this criterion later on. 

VII. Related work 

In [Kasal:2011:MDM:1955602.1956038], the 

authors present a survey on MDS. They propose an 
evaluation based on the work of Khwaja and Urban 
[doi:10.1142/S0218194002001062]. The study revealed that 
approaches that analyse implementations of modelled systems 
are still missing. Due to the fact that implementations 
are not generated automatically from formal specifications, 
verification of running code is reasonable. The main drawback 
of [Kasal:2011:MDM: 1955602.1956038] is that it is not a 
SLR. As a result, there are some well-known approaches that 
are missing in [Kasal:2011:MDM:1955602.1956038], such 
as SecureUML [Basm2006a]. 

In [Basin:2011:DMS:1998441.1998443], Basin et al. went 
through a “Decade of Model-Driven Security” by presenting 
a survey focusing on their specific MDS approach called 
SecureUML. The authors claim that MDS has enormous 
potential, mainly because Security-Design Models provide a 
clear, declarative, high-level language for specifying security 
details. The potential is even more, when the security models 
rely on a well-defined semantics. The main drawback of 
[Basm:2011:DMS:1998441.1998443] is that it only considers 
the work around SecureUML. 

[Uzunov: jucs ’ 18'20: engineering ’ security ’ into' distributed] 
is a survey of model-based security methodologies 
for distributed systems. The papers surveyed in 

[Uzunov:jucsl8’20:engineeringsecurityintodistributed] 
are not only about model-driven methodologies but 
also architecture-driven methodologies, pattern-driven 

methodologies, and agent-driven methodologies. Thus the 


































focus is not specifically MDS but rather security engineering 
for distributed systems in general. Our paper explicitly targets 
MDS methodologies as described in the previous sections. 

In [AdvMDS], five well-known MDS approaches, i.e. 
UMLsec, SecureUML, Sectet, ModelSec, and SecureMDD, 
are summarised, evaluated, and discussed. These five 
MDS approaches are also confirmed in this paper. It can 
be seen that our SLR results are complementary to the 
contributions of the normal survey papers, e.g. [AdvMDS], 
[Uzunov:jucsl8'20:engineeringsecurityintodistributed]. 
Those survey papers perform in depth analysis of some 
significant MDS approaches by elaborating one after another. 
But our SLR performs a SLR in both width and depth of MDS 
research which result in not only (evidently) significant MDS 
approaches but also emerging considerable MDS approaches. 
It is the first MDS literature review that systematically 
considers all relevant publications using explicit evaluation 
and extraction criteria. Furthermore, our SLR provides a 
detailed look at all the key artefacts of any MDS approaches 
such as modelling techniques, security concerns, how model 
transformations employed, how verification and validation 
methods used, and case studies, and application domains. We 
also provide a trend analysis for the development of MDS 
research area. 

[Jensen:2011:SMD:2065363.2066253] is closer to our 
SLR. The authors propose three research questions with the 
goal to determine if the current MDS approaches focus on 
code generation or having empirical studies. The study shows 
that there is a need for more empirical studies on MDS (none 
exists), and that standardisation is key to achieve the objectives 
of MDD/MDS (which are increased portability and inter¬ 
operability). However, [Jensen:2011:SMD:2065363.2066253] 
presents several drawbacks and differences from our paper. 
First, their search strategy is very limited compared to our 
three-pronged search strategy. Second, concerning the SLR 
protocol, no evaluation criteria and data extraction strategy 
are given. Moreover, their exclusion criteria are very nar¬ 
row. Consequently, the authors exclude significant papers in 
the field, e.g. UMLsec papers. Also, the authors exclude 
AOM approaches, because they consider that AOM does not 
consider security aspects as specific aspects (i.e. different 
from other aspects). Our work covers all the limitations 
of [Jensen:2011:SMD:2065363.2066253] and provides much 
more extensive SLR on the topic. 

VIII. Conclusions 

We have presented an extensive systematic literature review 
on model-driven approaches for developing secure systems. 
The SLR is based on a rigorous three-pronged search process, 
which combined automatic search and manual search with 
snowballing strategy. Using 9 clearly predefined selection 
criteria, 108 MDS papers have been strictly selected, and then 
reviewed. From these primary MDS papers, we extracted and 
synthesised the data to answer our research questions. 

The results show that most MDS approaches focus on 
authorisation and confidentiality while only few publications 


address further security concerns like integrity, availability, 
and authentication. Moreover, security concerns are often dealt 
with separately. Very few MDS approaches tackle multiple 
security concerns simultaneously, systematically. Not only 
multiple security concerns are less tackled, but also the inter¬ 
relations among security concerns are rarely taken into account 
systematically in MDS approaches. All these findings urge for 
more attention from the MDS research community to the less 
tackled security concerns, to the solutions that can deal with 
multiple security concerns simultaneously, systematically. 

Most of the approaches try to separate security concerns 
from core business logic, but only few weave security aspects 
into primary models. The UML profile mechanism is often 
used for the definition of security-oriented DSLs, but some 
approaches have introduced non-UML based DSLs. It can be 
understandable that standardised, common UML models are 
broadly used by MDS approaches. Anyway, defining DSLs 
plays a key role in MDS because that way allows better 
capturing the specific semantics of security concerns. Still few 
security modelling languages are introduced with a thorough 
semantic foundation, which is needed for automated formal 
analyses. Most of the MDS papers use only structural models. 
Using solely one type of models could not be enough to be 
able to express multiple security concerns simultaneously. 

MMTs and MTTs are important in any MDE approach. In 
MDS, MMTs and MTTs are often used but implementation 
details and tools are not often provided. Many examined MDS 
papers do not specifically provide any implementation infor¬ 
mation about MMTs. These papers just provide mapping rules 
for transforming models, or even without clearly defined trans¬ 
formation rules/mappings. Among the transformation tools 
provided or mentioned, not only general-purpose MMT and 
MTT tools but also many ad-hoc, specific (Java-based) tools 
are used. Developing tool chains (based on MMTs and MTTs) 
to derive from models to implementation code is an important 
piece of future work. Few complete tool chains to automate 
(most of) the MDS development process have emerged, but 
are very rare. Most approaches discuss illustrative examples or 
academic case studies but lack in-depth evaluations, e.g. using 
common benchmarks or empirical studies. Altogether, our 
literature review shows that many MDS approaches are suc¬ 
cessful for specific, isolated security concerns or application 
domains, but lack formality, automation, process-integration 
and evaluation. 

In our review, we have identified 5 principal MDS studies 
which seem more mature than the others. On the other hand, 
there are also other emerging/less common MDS approaches 
that we have found out. Another important finding comes from 
the trend analysis on the key artefacts of MDS over more than 
a decade. We can see that there was a peak time of MDS 
publications in 2009. After that, the trend of primary MDS 
publications looks more stable. The 1ST journal and MODELS 
conference are so far the most popular venues for publication 
of MDS papers. 

Our SLR protocol and the list of finally selected MDS 
papers could be used as the base for a follow-up SLR of MDS 



in the future. A reviewer would need to check again the cita¬ 
tion criterion for those primary MDS papers using up-to-date 
citation numbers on Google Scholar. After obtaining a subset 
of MDS papers from the original set, a forward snowballing 
on that subset should be conducted. Only forward snowballing 
is required in this step because new, extra MDS papers will 
only be found in this way. After reviewing and selecting a 
new set of MDS papers from the forward snowballing step, 
the full snowballing process can be operated on the new set. 


The finally newly found MDS papers after snowballing will 
be included into the base subset to form a new final set for 
data extraction, synthesis, and analysis. 
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